Finding the Source of Type Errors Interactively ( Draft )

1 Introduction All modern functional languages use variants of the Hindley/Milner type system. This system is quite exible since it allows values to have more than one type, and it is convenient because types can be derived automatically, making explicit type declarations unnecessary. Most trivial programming errors cause the type-deriver to emit error messages, which are usually easy to understand. However, the code where an inconsistency is detected is sometimes not the code that caused the error. When the type-deriver reports an inconsistency at the wrong place, most programmers use cumbersome trial-and-error to nd their mistake: either they give types to expressions manually and recompile until the type-deriver disagrees, or else they remove large parts of the program and recompile until the error disappears. Can we improve this situation? We could try to make the type-deriver better at pinpointing the real error, but we should not expect full success, since the location of a type error is subjective and depends on the programmer's intentions. This paper gives the outline of a type-deriver that can explain its reasoning in response to questions. First, we should be able to point at a subexpression and ask what type it has; such an interface has been implemented by Jan Sparud at Chalmers [6]. Second, we should be able to ask why a certain type has been derived; such a type-deriver has been implemented by Mitchell Wand [7]. When an error is detected, Wand's type-deriver suggests a number of possible error sites. One of these should be the subjective error, but sometimes too many possibilities are given. Therefore, I will propose an interactive way to access the information provided by Wand's type-deriver. Warning: The paper describes work that has hardly begun. I have not implemented anything, and realistic hand-simulations are dicult. But I do think an interactive interface is important: the type-deriver knows the type of every subexpression and how they were derived, but since it does not know the programmer's intentions and mistaken beliefs, it cannot decide by itself how much to tell. And if it tells all it knows at once, the programmer will be swamped.